監控（Monitoring）是橫跨多個世代確保系統穩定的維運技術，而 Metrics 就是其關注的焦點；同時 Metrics 也是 Observability 的重要基石。特別是在實踐 SRE（Site Reliability Engineering，網站可靠性工程）時，主要的概念如 SLI（Service-Level Indicator，服務水準指標）、SLO（Service-Level Objective，服務水準目標）以及 SLA（Service-Level Agreement，服務水準協議）都是以 Metrics 為核心。這些概念幫助我們定義什麼是重要的指標，這些指標需要達到什麼水準才算合格，以及如何對這些指標作出承諾。透過遵循這些概念，能讓我們確保系統的穩定性，並妥善地管理系統。

管理大師彼得杜拉克：「如果你不能衡量它，就不能管理它」

讓我們先來思考指標通常包含哪些要素。以體溫當作指標為例，在 2019 年 COVID-19 剛開始的初期，因為還沒有快篩，發燒成了一個重要的確診徵兆。家家戶戶都在量體溫，像我們公司內部也開始實施每日體溫測量，每個人的測量結果會紀錄在一張表上。首先，我們要測量的「體溫」就是指標的名稱；其次是測量到的「數值」；第三是測量的「時間」，因為一天內可能需要多次測量；最後是其他的「補充資訊」，例如被測量人的姓名、組別等。這樣一張張的表格組合起來，就可以獲得橫跨不同時間點的體溫數據。由於資料會根據時間不斷紀錄，這類資料被稱為時間序列資料（Time Series Data）。

通常，時間序列資料會存放在特別設計的時間序列資料庫（Time Series Database）中。相對於一般資料庫，這類資料庫是專為寫入和查詢優化，因為修改和異動的機會很少。另外，通常我們會想關注特定時間的狀況，即以時間區間作為篩選條件。因此，時間序列資料庫針對這些特性進行了優化，以提供更好的效能。

指標資訊的處理流程

在本系列中，Metrics 主要皆以 Prometheus Metrics 為主進行討論。以下就他的四個處理階段進行說明：

1. 生成

   Prometheus Metrics 由四個部分構成：

   1. 指標名稱：說明指標內容，有些指標會加上單位，例如：process_time、memory_usage_byte
   2. 時間：測量該指標的 Unix timestamp，單位為毫秒（milliseconds）
   3. 數值：指標的值，數值格式為 Float64
   4. 補充資訊：可有多組的 Key-Value Pair 資訊，例如：os=ubuntu、ip=1.1.1.1

   應用程式可以透過 Prometheus Client Library 生成 Prometheus Metrics。有官方以及第三方的多種不同語言 Library，另外也有針對機器或服務設計的各種 Exporter 能夠自動採集資料轉換成 Prometheus Metrics。

   
   Java Spring Boot Application 的 Prometheus Metrics

2. 收集

   從產生 Metrics 的服務角度來看，主要分為 Pull 與 Push 兩種模式：

   1. Pull 模式：通常稱為 Scrape，是 Prometheus Metrics 最常使用的模式，產生 Metrics 的服務揭露 Metrics 資訊，由 Prometheus 定期將 Metrics 收走
   2. Push 模式：通常稱為 Write，由產生 Metrics 的服務將 Metrics 推送到 Prometheus Pushgateway，之後再由 Prometheus 定期將 Metrics 從 Pushgateway 收走

   
   Prometheus Metrics 收集架構圖

3. 儲存

   Prometheus 預設會將資料儲存於本機磁碟的時間序列資料庫中。視資料的應用情境，若需要保存大量或長期的資料（例如超過千萬筆時間序列）時，官方建議搭配其他的儲存解決方案，例如接下來我們會介紹的 Mimir、Cortex、Thanos。

4. 使用

   儲存後的 Prometheus Metrics 可以使用專屬的 PromQL 語法查詢指標，或者搭配 Grafana 建立 Dashboard 以不同的視覺化方式檢視指標。

   
   PromQL 查詢結果

小結

以上即為 Metrics 的簡易介紹。接下來的章節將詳細介紹 Prometheus、Exporter、各種儲存解決方案，以及另外兩個也在 Metrics 領域深耕許久的 StatsD 和 Zabbix。